Sports pool web application

ABSTRACT

A computer readable medium containing computer executable instructions, which, when executed by a computer, perform the steps of (a) generating one or more pools, (b) generating a set of random numbers for each of the one or more pools when the one or more pools are generated, (c) encrypting each set of random numbers and (d) generating instructions to display a graphical representation of the one or more pools in response to a user request. The graphical representation comprises a plurality of graphical devices, each aligned with a respective row or column of a grid. The graphical devices display the set of random numbers after performing a predetermined animated sequence.

This application claims the benefit of U.S. Provisional Application No. 60/797,158, filed May 3, 2006 and is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to a method and/or architecture for a web/network application generally and, more particularly, to a sports pool web application.

BACKGROUND OF THE INVENTION

In offices and local bars during sports seasons, a 10×10 grid is often used by players for entertainment or to win money based upon the outcome of an event such as a baseball, basketball, soccer or football game. Players buy squares on the 10×10 grid. Once the squares of the grid have been sold, numbers between zero and nine are randomly selected and assigned to each column and row of the grid. At the end of a quarter or a period in the particular event, the last digits in the scores of the competing teams are compared to the numbers along the rows and columns. Squares located at an intersection of a column and a row with the appropriate numbers corresponding to the score are considered winners for that period or quarter. Depending upon where a player is located, the events for which the player can participate can be limited.

It would be desirable to have a sports pool web application that may be accessed via the internet and would allow a player to select from any or all events occurring at any given time for entertainment or permit transmission of information relating to betting on particular events between jurisdictions in which such betting is legal.

SUMMARY OF THE INVENTION

The present invention concerns a computer readable medium containing computer executable instructions, which, when executed by a computer, perform the steps of (a) generating one or more pools, (b) generating a set of random numbers for each of the one or more pools when the one or more pools are generated, (c) encrypting each set of random numbers and (d) generating instructions to display a graphical representation of the one or more pools in response to a user request. The graphical representation comprises a plurality of graphical devices, each aligned with a respective row or column of a grid. The graphical devices display the set of random numbers after performing a predetermined animated sequence.

The objects, features and advantages of the present invention include providing a sports pool web application that may (i) be accessed by players from all over the globe, (ii) provide entertainment, (iii) include an animated drawing of numbers, (iv) automatically generate new pools as existing pools fill up, (v) provide a wide range of pools from which players can select and/or provide a number of new sport pool variations (e.g., speed pools, mini pools, private pools, bonus pools, mega pools, etc.).

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features and advantages of the present invention will be apparent from the following detailed description and the appended claims and drawings in which:

FIG. 1 is a block diagram illustrating an overall view of a sports pool web application in accordance with the present invention;

FIG. 2 is a block diagram illustrating a process for determining winners;

FIG. 3 is a block diagram illustrating a process for determining whether a pool is official or not;

FIG. 4 is a block diagram illustrating approaches for selling squares;

FIG. 5 is a block diagram illustrating an administrative process in accordance with a preferred embodiment of the present invention;

FIG. 6 is a block diagram illustrating a user interface process;

FIG. 7 is a diagram illustrating an example game board; and

FIG. 8 is a diagram illustrating another example of a game board.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to FIG. 1, a block diagram is shown illustrating an overview of a sports pool web application 100 in accordance with a preferred embodiment of the present invention. In one example, the sports pool web application 100 may include a member interface block 102, an administration interface block 104, a website/data integration interface block 106, a game logic block 108, a pool creation block 110 and a random number generation block 112. The member interface 102 is generally configured to provide routines that allow registration of new members and access to member information by already registered members. The member interface 102 may be further configured to manage member related processes such as collection of bets, payment of winnings, collection of member information, communication of game outcomes and selection of available games.

In one example, the web application 100 may be interacted with by accessing a website. Visitors (or members or players) to the site may register by, for example, entering in their personal information along with an e-mail address and selecting a username and password of their choice. The username selected is generally checked for uniqueness, and may be the only information about the member that is displayed to other users. Registering may also allow visitors the option of entering which payment types they would like to use to transfer monies to and from their account.

A visitor to the site logs in before being able to select squares. Due to the association of squares with wish lists during a purchasing process, visitors that are not logged in may only view the pools that are available and not place any on a wish list. Logging in also provides visitors with the ability to access their account options and view previous transactions.

Visitors may browse through, or sort, the available pools by sport, division, league, team, game date, dollar amount (or denomination), or pool square payout type or percentage. Visitors, who are logged in, can add squares to their wish list. When squares are added to their wish list, the selected squares are associated with their member account for a predetermined period (e.g., two hours). The predetermined period may be set (or programmed) by the site administrator. In one example, the predetermined period is programmable as a global parameter. After the predetermined period of time has expired, the squares may be automatically removed from the wish list and disassociated from the particular member account.

In general, when squares are selected, the choices are added to the wish list. At the time of actual purchase, the choices are refreshed to determine whether the squares on the wish list are still available. Though a square is on a number of wish lists, the square may be purchased by another visitor. In general, priority is given to the visitor purchasing a square. The priority for purchasing squares generally prevents someone from just reserving squares for inappropriate amounts of time and never actually purchasing the squares. The priority for purchasing squares also acts as an incentive to visitors to buy squares immediately or risk losing the squares.

The squares generally provide (or show) an indication that they are on a wish list (e.g., the username of any members who have the square on their wish list). Showing the other members who have a selected square on their wish list also may act as an incentive to encourage immediate purchase when squares are first selected by a visitor. For example, a first visitor may sign onto a particular site and select a square to put on their wish list. A second visitor signing onto the site will see the selected square with an indication (e.g., color, etc.) that the square is on a wish list. If the second visitor selects the square for addition to their wish list, the second visitor may receive a list of all the wish lists on which the particular square has been placed. Seeing the number of wish lists having the square may prompt the second visitor to buy the square immediately.

When a visitor has finished selecting squares, the visitor may be directed to a buy now option. The buy now option provides the visitor with the option to review and/or remove squares that were selected while browsing the site, or to continue purchasing the squares. Squares removed from the wish list by the visitor will have an indication immediately changed to show the visitor no longer has an interest in the squares (e.g., a color of the squares may be changed, name removed, etc.). The buy now option will display a summary of the pool(s) that the visitor is in, a graphical representation of the squares that the visitor selected, the game(s), as well as their time(s), and the price of each selection that was made, along with the total. In one example, a list of squares may be displayed and details accessed by clicking on individual entries in the list.

Once the visitor has reviewed their selection during the purchase process, the visitor will be provided with a total for the cost of the transaction. The visitor then commits to the transaction based on their account. The visitor may directly apply funds for the transaction through a chosen method of payment set up in their account.

Visitors generally have the ability to update their account information (e.g., address, contact information, payment information, etc.). Visitors can review their account balances, add funds through payment types, and receive payouts from winnings. Visitors can also view their transaction history.

The administration process 104 may be configured to facilitate configuration (programming) of global parameters, including default values, for controlling various processes involved in the web application 100. For example, the administrative process 104 generally includes routines that allow an administrator to set the number of pools to be generated, the price charged for each pool, when a pool is official, when pools are closed to further sales, amount of payouts, the type of pools to be presented, the type of payout for each pool, etc.

The website/data integration interface 106 may be implemented to interface the web application 100 to already existing websites and/or databases. For example, the website/data integration interface 106 may be configured to connect the application 100 to a website previously set up to handle payment transactions, wagering on events, and other related activities. The website/data integration interface 106 may be further configured to facilitate the import and export of data between the web application 100 and other websites and applications.

The game logic block 108 may be configured to provide the overall game operation of the sports pool web application 100. For example, the game logic 108 generally controls the game play and game flow, as well as the array of available games in which visitors may partake.

The pool creation block 110 is generally configured to generate a number of pools based upon predetermined criteria set through the administration process 104. For example, the pool creation process 110 may be configured to generate one or more pools for each of a number of events which are set to occur.

The random number generation block 112 may be configured to generate sets of random numbers for each pool generated in the pool creation block 110. In general, the block 112 is configured to generate the set of random numbers for each pool at the time the pool is created. By generating the set of random numbers at the time a pool is created, the process 112 generally reduces the amount of processing bandwidth needed when generating the random numbers for the pools. For security of the pools, the sets of random numbers generated for each pool are encrypted prior to being stored. The random number generation block 112 may be implemented as a software, hardware or combination hardware/software random or pseudo-random number generator and encoder.

Referring to FIG. 2, a block diagram is shown illustrating a process 120 for determining winners of the pools. The process 120 may comprise a block 122, a block 124, a block 126, a block 128, a block 130, a block 132, a block 134 and a block 136. In one example, the block 122 may be implemented as a start of game detection block. The block 124 may be implemented as a statistics retrieval block. The block 126 may be implemented as an end of period or end of quarter detection block. The block 128 may be implemented as a winning square determination block. The block 130 may be implemented as an end of game determination block. The block 132 may be implemented as a certification block. The block 134 may be implemented as a notification block. The block 136 may be implemented as a winnings payout block.

The process 120 is generally executed within the game logic 108. For each pool created by the pool creation block 110, the process 120 first enters the state 122 to determine whether an associated game has started. When the game has not been started, the process 120 generally waits in the state 122, with respect to the unstarted game, until the game has started (e.g., the path NO from the block 122). Multiple instances of the process 120 may be running simultaneously. When the game associated with the particular pool has started, the process 120 generally moves to the state 124. In the state 124, the process 120 generally retrieves statistics regarding the game (e.g., scores, etc.). The process 120 may move from the state 124 to the state 126 or the state 130 depending upon the statistics.

In the state 126, the process 120 generally determines whether a quarter or period of the particular game has ended. When the quarter or period of the particular game has not ended, the process 120 generally returns to the state 124. When the quarter or period of the particular game has ended, the process 120 generally moves to the state 128. In the state 128, the process 120 generally determines whether a winning square is present based upon the statistics (e.g., the score of the game). Once the winning square has been determined, the process 120 generally moves to the state 130. In the state 130, the process 120 may be configured to determine whether the particular game has ended. When the game has not ended, the process 120 generally returns to the state 124. When the game has ended, the process 120 generally moves to the state 132.

In the state 132, the process 120 is generally configured to certify the final scores of the game. Once the scores have been certified, the process 120 generally moves to the state 134 and the state 136. In the state 134, the process 120 generally notifies winners (e.g., by e-mail, instant messenger, etc.). In the state 136, the process 120 generally provides for payment of winnings to the winners (e.g., into an established account) based upon game and/or pool rules. The operations performed in the state 134 and the state 136 may be performed simultaneously or in sequence.

Referring to FIG. 3, a block diagram is shown illustrating an example of a process 150 for determining whether a pool is official. The process 150 may comprise, in one example, a state 152, a state 154, a state 156, a state 158, a state 160, a state 162 and a state 164. The state 152 may be implemented as a bidding closed state. The state 154 may be implemented as a checking state. The state 156 may be implemented as a decision state. The state 158 may be implemented as an enabling state. The state 160 may be implemented as a decision state. The state 162 may be implemented as a housekeeping state. The state 164 may be implemented as a refund state.

In one example, the web application 100 may be configured to stop accepting bids based upon one or more predetermined criteria (e.g., a predetermined amount of time before a game starts). Once the predetermined criteria are met, the web application 100 may execute the process 150 for the particular pool by entering the state 152. Multiple instances of the process 150 may be running simultaneously. The process 150 may move from the state 152 to the state 154. In the state 154, the process 150 generally determines the number of purchased squares in the particular pool and moves to the state 156. In the state 156, the process 150 checks to determine whether all of the squares in the particular pool have been sold. When all the squares have been sold, the process 150 generally moves to the state 158. When less than all of the squares have been sold, the process 150 generally moves to the state 160.

In the state 158, the process 150 generally allows for (or enables) viewing of the drawn numbers. For example, until the viewing of the drawn numbers is enabled (or allowed), each of the displays showing particular pools has the positions where the numbers corresponding to the scores are to be shown obscured by predetermined graphics or icons (e.g., playing cards, slot machine wheels or other graphics). When the display of the drawn numbers is enabled, the graphics may be animated to show the drawing of the numbers (e.g., the cards flip over, the slot machine dials spin and stop on the numbers, etc.).

In the state 160, the process 150 generally determines whether the number of squares sold meets a predetermined threshold. In one example, the threshold may be set to insure the game does not lose money. When the number of squares sold meets or exceeds the predetermined threshold, the process 150 generally moves to the state 162. When the number of squares sold is less than the predetermined threshold, the process 150 generally moves to the state 164. In the state 164, the process 150 may be configured to refund all purchase prices on the squares in the particular pool.

In the state 162, the process 150 may be configured to assign all unpurchased squares in the particular pool to the house (e.g., the entity operating the web application 100). In one example, the process 150 automatically selects random names that may be placed in the squares to indicate to anyone accessing the pool that the squares are no longer available. When the pool has been updated to show that all the squares are no longer available, the process 150 may move to the state 158.

Referring to FIG. 4, a block diagram is shown illustrating an example of a process 180 for selling squares in accordance with a preferred embodiment of the present invention. The process 180 may comprise a state 182, a state 184, a state 186, a state 188, a state 190, a state 192, a state 194 and a state 196. When a visitor to the web site hosting the web application 100 indicates that squares in particular pools are to be purchased, the web application 100 may enter (execute) the process 180 by entering the state 182.

In the state 182, the member or visitor is allowed to select squares from one or more pools available. When a square has been selected, the process 180 may move to the state 184 or the state 188, depending on whether the member wishes to wait on purchasing a square or immediately purchase a square. When the member wishes to wait on purchasing a square, the process 180 may move to the state 184 and place the selected square on a wish list associated with the member ID. The process 180 may then move to the state 186 and update member information regarding the wish list of the member.

When the member decides to immediately purchase the square, or the member, while looking at the wish list, decides to purchase the squares on the wish list, the process 180 moves to the state 188. In the state 188 the process 180 may execute a routine for purchasing the squares which have been selected by the member. For example, the process 180 may go to the state 190 to link to member information concerning a member account to charge the appropriate amounts for the squares purchased.

When the square purchasing transaction is completed, the process 180 may move to the state 192. In the state 192, the process 180 may determine whether a new pool is needed based upon predetermined criteria (e.g., the current pool is full, the current pool is official, etc.). When a new pool is not needed (e.g., existing pools are not filled and time remains before bidding is closed), the process 180 may move to the state 194. When a new pool needs to be created, the process 180 may move from the state 192 to the state 196. In the state 196 the process 180 may create a new pool with the same attributes as the current pool (e.g., game, square cost, payout type, etc.) and generate a new set of random numbers. Once the new pool has been created and the new random numbers have been encrypted and stored, the process 180 may move from the state 196 to the state 194. The state 194 generally provides an exit (or stop) state of the process 180.

Referring to FIG. 5, a block diagram is shown illustrating an example of an administrative process 200 in accordance with a preferred embodiment of the present invention. The process 200 may be implemented to control administrative functions of the web application 100. The process 200 may comprise a state 202, a state 204, a state 206, a state 208, a state 210, a state 212, a state 214, a state 216, a state 217, a state 218, a state 220, a state 222, a state 224, a state 226, a state 228 and a state 230.

The state 202 may comprise overall administrative functions of the process 200, allowing an administrator of the web application 100 to select and manage various functions of the web application 100. In one example, an administrator may select to configure global and/or default settings of the web application 100. When an administrator selects to configure the global and/or default settings of the web application 100, the process 200 may move to the state 204. In the state 204, the process 200 may be configured to facilitate the configuration of global settings for the web application 100. For example, the process 200 may query the administrator to enter values and accept input from the administrator regarding content management and/or betting configuration. For example, through the content management function help menus and text throughout the web application may be added or altered according to administrative preference. For example, the administrator may set what options are available to members on the opening screen and include a selection of featured games (or hot pools) to which the administrator wants the member's attention drawn.

The betting configuration function generally allows adding and/or adjusting global and/or default settings according to administrative preference. Global and default settings may include, but are not limited to, the number and types of games to be offered, the number and types of pools to be offered, the denominations (e.g., cost of squares) of the pools to be offered, the default denominations to be generated, default currency, the times for ending bidding, the thresholds for declaring pools official, the types of payouts for each pool, the drawing time for pools when numbers can be viewed, an auto-create threshold for determining how many squares need to sold before a new pool or pools are generated, a wish list expiration time (e.g., the amount of time a square will remain on a customer wish list), a parameter setting a time that pools and results are available to customers after a given game, etc. In one example, the web application 100 may comprise a number of default settings to allow immediate operation of the web application 100 without the administrator performing custom configuration. When the default configuration is selected, the process 200 may move to the state 206. In the state 206, the process 200 may select predetermined default values for one or more parameters within the web application 100.

When the web application global parameter values have been set, the web application 100 may be configured to automatically begin setting up pools to be offered to members. In one example, the process 200 may move to the state 208. In the state 208, the process 200 may be configured to manage parameters regarding the sports games. The state 208 may provide, for example, (i) generation of defaults for loading schedules, (ii) individual control over loading any particular game and creating any pools for the particular game, (iii) setting filter controls for searching sports, leagues, teams, etc., (iv) control of multiple pool generation, (v) import information regarding a number of games for which pools are to be generated, and (vi) automatic number generation for pools.

For example, when information regarding the particular games being offered has been imported, the process 200 may move to the state 210. In the state 210, the process 200 may begin configuring the pools for each of the particular games. For example, values in each of the pools regarding which teams are associated with the pool may be set. In one example, the process 200 may use custom or default settings set during the configuration stage 204 when configuring the games and pools.

When the process 200 has completed configuring the games and pools parameters, the process 200 may move to the state 214. In the state 214, the process 200 generates the pools. Once the pools are generated, the process 200 may move to the state 216 to generate random numbers for each of the pools. In one example, the process 200 may be configured to generate a pool and then generate the random numbers for the pool. The process may be repeated until all of the pools to be generated have been generated. In general, by generating the random numbers for each pool at the time the pool is created, the present invention may provide an advantage of reducing the amount of processing bandwidth used for generating the random numbers.

When the process 200 is activated by an administrator to set up pools, the process 200 may move to the state 217. In the state 217, the process 200 may provide the filtering tools to establish search criteria for all games with pools, number of pools and viewing options for pools.

When the process 200 is activated by an administrator to review member transactions, the process 200 may move to the state 218. In the state 218, the process 200 may be configured to provide information about member transactions to the administrator. For example, the process 218 may be configured to move to the state 220 to show overall program member statistics, to the state 222 to show purchase statistics, to the state 224 to show win statistics and to the state 226 to display a list of members. When the process 200 is in the state 220, the process 200 may be configured to show statistics including, but not limited to, total transactions, total members, total members with active bets, and total number of active bets. When the process 200 is in the state 222, the process 200 may be configured to show statistics including, but not limited to, total number of purchases, total amount of purchases and purchases average. When the process 200 is in the state 224, the process 200 may be configured to show statistics including, but not limited to, total number of wins, total winnings amount and average winnings. When the process 200 is in the state 226, the display of the list of members may be expanded by moving to the state 228. In the state 228, the process 200 may be further configured to show every detail of member accounts and activity.

When the process 200 is entered by an administrator to review house transactions, the process 200 may be configured to move to the state 230. In the state 230, the process 200 may be configured to provide information about house transactions to the administrator. For example, the process 230 may be configured to move to the state 232 to show overall statistics, to the state 234 to show purchase statistics, to the state 236 to show win statistics, to the state 238 to display current active house bets and to the state 240 to display a list of house transactions. When the process 200 is in the state 232, the process 200 may be configured to show statistics including, but not limited to, total number of transactions and total number of active bets. When the process 200 is in the state 234, the process 200 may be configured to show statistics including, but not limited to, total number of purchases, total amount of purchases and average purchases. When the process 200 is in the state 236, the process 200 may be configured to show statistics including, but not limited to, total number of wins, total winnings amount and average winnings. When the process 200 is in the state 238, full details about every pool in which the house currently has bets may be reviewed. When the process 200 is in the state 240, a history of house transactions and expandable details about each pool and bet may be reviewed.

Referring to FIG. 6, a block diagram is shown illustrating an example of a user interface process 250 for facilitating user interactions with the web application 100. In one example, the process 250 may include a state 252, a state 254, a state 256, a state 258, a state 260, a state 262, a state 264, a state 266, a state 268, a state 270, a state 272, a state 274, state 276, a state 278 and a state 280. In general, the process 250 may be executed from the member area 102. In one example, the process 250 may move to the state 252 in response to a member request to look for available pools.

In the state 252, the member may set parameters for searching for pools based on sport, leagues, teams, game date, dollar amount, events, payouts or other parameters (e.g., speed pools, mini pools, private pools, bonus pools, mega pools, etc.). Upon a selection of particular parameters for the pool or pools to play, the process 250 may move to the state 254. In the state 254, the process 250 may select the pool or pools meeting the member's search criteria. For example, the member may select one or more pools from a particular game. Upon selecting the pools, the process 250 may move to the state 256. In the state 256, the process 250 may allow the member to select squares. The process 250 may query the member whether to buy the selected squares immediately or put the selected squares on a wish list.

When the user chooses to buy the selected squares immediately, the process 250 may move to the state 258 and allow the member to buy the squares. When the member chooses to put the squares on a wish list, the process 250 may move to the state 260 and allow the member to put the squares on a wish list associated with the member's ID. When the member has put selected squares on the wish list, the process 250 may be configured to move to the state 262 in response to a later decision by the member to buy the squares on the wish list. In the state 262, the process 250 may be configured to check the availability of the squares on the member's wish list and indicate which squares are still available to the member. When the member decides to buy the squares which are still available, the process 250 may move to the state 264 and allow the member to purchase the squares immediately. A list of expired squares may also be displayed.

When the process 250 has been activated in response to a member request to check the current status of previously placed wagers, the process 250 may enter the state 266. In the state 266, the process 250 may be configured to allow the user to access information about current bets and pools. In one example, the process 250 may move to the state 266 to provide views and/or printouts of the bets and pools of the particular member. For example, the process 250 may move to the state 268 to display the current bets and/or pools or the process 250 may move to the state 270 to allow the member to print out copies of current bets and pools.

The member may also choose to print detailed versions of individual pools. For example, in response to a request from the member the process 250 may move to the state 272. In the state 272, the process 250 may provide options for the member to either view details of the particular pools for which squares have been purchased (e.g., by moving to the state 274) or to print out copies of the pools in which the member has purchased squares (e.g., by moving to the state 276). The process 250 may also be configured to allow a member to watch or replay the drawing of the numbers assigned to the horizontal and vertical axes of the pools in which squares have been purchased (e.g., by moving to the state 278).

A member may also be able to monitor betting history using the web application 100. In one example, when a member activates the process 250 to examine the transaction history, the process 250 may be configured to move to the state 280. In the state 280, the process 250 may be configured to display a detailed list or graphical representation of the member's transaction history. In one example, a list of transactions may be displayed. Selection of a particular transaction may result in a display of expanded detail for the selected transaction.

Referring to FIG. 7, a diagram is shown illustrating an example of one embodiment of a pool in accordance with the present invention. In one example, a pool 300 may be graphically presented to a member. The pool includes a 10×10 grid 302. At the top of the grid an area 304 may be reserved for graphical presentations of the numbers to be assigned to each column in the 10×10 grid 302. Also above the 10×10 grid 302, an area 306 may be reserved for providing an indication of the particular team represented by the numbers in the area 304. Similarly, on the left hand side of the 10×10 grid 302, an area 308 may be reserved for graphical indications of the numbers associated with each row of the 10×10 grid 302 and an area 310 may be reserved for indication of the team associated with the rows of the 10×10 grid 302. Other fields may be implemented accordingly (e.g., a clock showing time until drawing, a game title and/or status, a progressive jackpot counter, etc.) to meet the design criteria of a particular implementation.

In one example, the area 304 and the area 308 may be implemented with a graphical representation of a playing card for use in showing the numbers assigned to each column and row, respectively, of the 10×10 grid 302. For example, when display of the selected random numbers associated with the pool is enabled, a member may sign on and watch as the cards are turned over to reveal the numbers.

Referring to FIG. 8, a diagram is shown illustrating an example of another embodiment of a pool in accordance with the present invention. In another embodiment, the areas 304 and 308 may comprise graphical representations of a slot machine dial. When the display of the random numbers is enabled, the graphics of the slot machine dials may be animated to appear to be spinning and stopping one at a time to show the numbers corresponding to each of the particular columns and rows.

The present invention generally provides routines for managing membership, registration, administration and game operation. The member management routines may be configured, for example, to allow members to change member information, add/remove credit cards, show transaction history and show/track bets. The registration routines may be configured, for example, to add/delete members to a database and send e-mail confirmation of registration actions. The administration routines may be configured, for example, to (i) fetch sports games schedules from XML and add the schedules to the database, (ii) modify betting game settings for the sports games, (iii) view pools for the games, (iv) show a history of transactions, (v) show/modify member information and/or (vi) view “House” plays. However, other administration operations may be implemented. The game operation routines may be configured to (i) search and list games, (ii) create pools for games, (iii) create 100 square pools, (iv) set costs for each square at a predetermined (programmable or default) amount, (v) indicate whether squares are open, locked or on a wish list, (vi) determine whether to create new pool logic (e.g., when an existing pool is 80% full), (vii) determine when to set a pool as official (e.g., when a pool reaches 91% full), (viii) close a pool at a specified time before the game starts and/or (ix) buy remaining squares for the “House” when there are open squares and pool is filled to a predetermined level (e.g., 90%).

The present invention may implement a random number generating program for determining the numbers associated with row and columns in the pools. The program draws numbers 0-9 without repeats for the columns and for the rows and stores the numbers in an encrypted format. The numbers are displayed for each pool in a fun way when the buying of squares is over. The present invention may be configured to read an XML feed every minute to update the scores and times. When a quarter/game is over, the present invention determines a winner and handles payment of winnings.

The list of games to have pools will be generated and maintained via the Administration routines. For example, an administrator logs into the system, presses a button which will retrieve the available games, and then selects the games that will be available to the members. Once the games are set up, the members will be able to search for a game by date, team or by a listing of all the games. All pools are numbered administratively, allowing both the customer and administrator to differentiate one game from another. For instance several $5.00 dollar pools for the same game at the same time may have been generated and sold out. Each will have an administrative number assigned (i.e., pools 101, 102, 103, 104, etc.). Once a game is chosen, the member will be able to view the available pools for that game and can choose to join a pool based on how full it is and/or the dollar amount of the square.

When the pool is chosen, the member can then choose which square or squares to buy in the pool. As the member chooses a square, the square is added to their wish list and associated with the member ID. If the member decides not to buy the square(s), the square(s) is(are) disassociated from the member wish list. The square(s) will be associated with the member wish list for a predetermined amount of time (e.g., 3 hours) or until the square(s) is(are) released by the member. The predetermined amount of time may be programmable. If the member logs out of the system or looses connection, the member may re-visit within the predetermined amount of time and the wish list will be intact. However, if another player(s) has purchased item that were on the wish list of the disconnected player, the disconnected player would be alerted that the particular squares had been purchased and were no longer available.

When squares are placed on a wish list a customer, when viewing the list, may purchase all, purchase individually, or delete specific squares and purchase the remaining. When the square(s) are purchased there will be an indicator that the square(s) is(are) taken (e.g., username, graphic, color, etc.). The square count is then updated and a check runs to determine whether the pool is at a first predetermined threshold (e.g., 80% full). When the pool is at the first predetermined threshold, another pool may be created. When the pool is at a second predetermined threshold (e.g., 90% full), the game may be set to be official. The first and second thresholds may be programmable.

At a designated time before the game is ready to start, the drawing of the values for each row and column will begin. Drawing will only start for official games; other games will have the money refunded to the member. Once the drawing starts, the squares are closed for purchase and any additional squares will be purchased by the house. In one example, each pool for a particular game may start drawing at the same time. If a member has multiple squares in multiple pools, the member can have more than one “pop-up” window open to watch the drawing(s). The values may be drawn randomly with a value range of 0 thru 9. In one example, playing cards may be used to represent the numbers. In one example, the page may set the next value for the squares every 5 seconds moving left to right, top to bottom. Once the drawing is complete, an e-mail, or other notification will be sent to the member showing their values. When a pool is 100% sold out, regardless of the date and time that the game will be played, the numbers for the pool may be automatically drawn. This way, a customer can visit and view their numbers in a game and if they do not like them they can buy more squares in another pool before game day.

Scores of the sports game may be updated on the site according to a predetermined frequency (e.g., every minute). The frequency of update may be programmable. Depending on the betting game chosen for the pool, winners may be announced at the end of each quarter (e.g., on a “pool viewing” screen), as well as by e-mail. A member may have a “control panel” to see their progress with all of their squares. Winnings are paid depending on the type of betting game chosen for the pool. To prevent error, official notification to winners may be made after a predetermined amount of time following the end of any particular game. The predetermined amount of time may be set (programmed) in the administrative mode. At the time official notification is given, funds may be transferred to an account of the winner(s).

The present invention may provide a selection of a number of types of pools. In one example, the pools may have various type of payouts (e.g., straight, straight/reverse, progressive and progressive/reverse, etc.). In another example, the present invention may provide a selection of a number of new types of pools (e.g., speed pools, mini pools, private pools, bonus pools, mega pools, etc.).

Speed pools generally allow a visitor to browse and choose a game similarly to a regular pool. In one example, when the visitor decides on a game and a denomination, the appropriate game screen appears with individual squares, 100 in all, shadowed in the background. A purchase box (or button) may be presented (e.g., centered in the foreground) that allows the visitor to purchase a square immediately. For example, the purchase box may be labeled “Buy Now.” When the purchase box is selected (e.g., clicked), a square may appear with a number at one side and a number on top, which are the square numbers the visitor will have for the selected game. The label in the purchase box may be changed to “Try Again?.” If the visitor does not like the square numbers (e.g., the square is associated with a football game and the numbers received are 2 and 6), the visitor can continue purchasing squares until the numbers received are acceptable or until the last square of the pool is purchased. A message may be presented informing the visitor that he/she has just purchased the last square. For example, a message such as “Congratulations, you have purchased the final square in this pool, the pool is now official” may be presented to inform the visitor.

The speed pools type of sports pool may be most popular in the football forum because certain numbers are considered more favorable than other numbers. In general, a single pool per denomination is created at a time, with subsequent pools created each time the final square of a particular pool is purchased. When the pool is official, the visitor can view the entire pool (e.g., by selecting the view pools member option) and view the entire speed pool.

In one example, when the view speed pool option is selected, a display of the pool will open up showing the 100 squares. The squares may be highlighted in a random sequence until all of the squares are highlighted, including the ones the visitor purchased. During the highlighting process, the visitor will see where the purchased squares appear within the 100 square grid. The speed pool type of sport pool generally allows a player to continue buying squares until receiving numbers that are acceptable.

Mini pools are pools comprising 25 squares; five across and five down. Similar to regular pools, visitors can buy as many squares as they want. During the drawing process, two sets of numbers are generated for each square, as opposed to a single set of numbers in regular pools. Because two sets of number are associated with each square of a mini pool, the chances of winning are better (e.g., 1 in 12.5 or 1 in 8.3, depending on the type of payout chosen). Because two sets of numbers are associated with each square, the visitor may get two good sets, or a combination of good and/or bad sets (e.g., 2.6 and 7.7). Because the mini pool has only twenty-five squares, the mini pool type of sports pool may be used for several new applications (e.g., baseball, golf, hockey, etc.). For example, during a premier match-up between golfers (e.g., Woods v. Mickelson) pay-offs may be made at the end of nine holes and eighteen holes.

Private pools generally allow customers to limit access to the action. For example, a business may set up a private pool and limit access to employees; a bar may set up a private pool and limit access to patrons. In general, a private pool customer may pre-pay for (or buy) an entire pool up front and provide their employees or customers with access information (e.g., codes, passwords, etc.) to select one or more squares by accessing the pools game site and going to a private pools area. The availability of the private pools may provide benefits such as eliminating on premises money transactions, eliminating on premises pools, eliminating display of pools on premises to sell squares, and eliminating disputes over the legitimacy of the numbers drawn. The private pools type of sport pool may allow an entire pool to be purchased up front and squares given away as gifts. Each player can have access to their own copy of the pool simply by going on-line and printing a copy.

Unlike anything ever introduced before in the internet gaming arena, the “Mega Pools” feature of the present invention offers the player the same exciting action of being involved in a regular, straight or progressive football or basketball pool, with one major difference, a chance to win up to 10,000 times their original bet. For example, when a customer views the available Mega Pools, all Mega Pools have a “Progressive Jackpot Counter” affixed to the denominationally appropriate pools. To be in a Mega Pool, a player must win two rounds. The first round is his/her entry into a first pool by buying a square in a regular pool associated with the Mega Pool. As an example, a $5.00 football pool will be used illustrate a Mega Pool process in accordance with the present invention. The player simply purchases a square in the regular pool associated with the Mega Pool and awaits the outcome of the game. A Mega Pool generally provides for an additional winner (e.g., consolation prize winner) when compared to a regular pool. For example, unlike the regular straight football pool which has four winners, a Mega football pool has five winners; first Quarter, second Quarter, third Quarter, Final Score and Final Score Reverse. The first four winners receive the standard divisional payouts. The “Final Score Reverse” winner, or consolation prize winner, is automatically entered into a free “Bonus Pool” associated with the Mega Pool.

Each Bonus Pool is comprised of 100 squares. Since each Bonus Pool comprises 100 squares, it takes one hundred regular pools to fill one Bonus Pool. In all, one hundred Bonus Pools may be created and it will take 10,000 Final Score Reverse winners of the regular pools to fill the one hundred Bonus Pools. The total dollar amount generated, using the above example, from the square sales of 10,000 regular $5.00 pools is $5,000,000.00, of which a percentage may be taken as a fee (or rake) by the hosting site. In one example, ten percent of the sales may be kept as the fee and ten percent of that (or $50,000.00 in this example) may be set aside as the prize for the winner of the Mega Pool. One final score winner from each of the created Bonus Pools is automatically entered into the Mega Pool. The winner of the Mega Pool is determined based on the final score of a game announced at a later time. The Final Score winner of the Mega Pool receives the prize money (e.g., $50,000.00 in the above example).

Since the only payment by a player is when the player enters the Mega Pool by entering, for example, a $5.00 pool (e.g., the player is automatically entered into the Bonus Pool upon winning the $5.00 pool as the “Final Score Reverse” winner and is then automatically advanced to the Mega Pool upon winning the Bonus Pool as the “Final Score” winner of the Bonus Pool), the “Final Score” winner of the “Mega Pool” takes home up to 10,000 times their original $5.00 bet. The odds of winning the Mega Pool may be calculated as 1 in 100 in the first pool, 1 in 100 in the Bonus Pool and 1 in 100 in the Mega Pool, or one in a million in the regular pool first round, one in ten thousand in the bonus pool second round and finally 1 in 100 in the “Mega Pool” final round. However, from the player's viewpoint, the player only has to win three times, each with 1 in 100 odds.

From a marketing standpoint, one could advertise that “For a chance to win up to 10,000 times your bet, purchase one square from any of the pools featured on the “Mega Pool” list. In addition to the standard winners, an additional winner will receive, as a consolation prize, one entry into a “Bonus Pool”, where your odds are 1 in 100 to win and move forward as one of the final 100 participants for a chance to win up to 10,000 times your original bet.”

Since the inception of internet wagering, marketing teams across the world have looked for ways to attract new action on old games. Introducing new versions of the sports squares game into the gaming arena is no different. The question becomes, “How to pull that demographic out of the office and bars, away from “office pools” and “bar pools” and into internet sites. Mega Pools provides a chance to win up to 10,000 times the original wager which provides an opportunity not available in an office pool or bar pool.

With Mega Pools, entering a pool is not game specific. A player does not really care who else is playing. Rather, the player just wants to get into a regular pool, win the consolation prize, move to the bonus round and then on to the final round. Along the way, 40,000 winners will get paid in the first round regular pools, via normal pool payouts, and 10,000 consolation prize winners will move into the bonus round, from which one hundred will move to the mega round. However, in the mega round only one will emerge victorious. The Mega Pools in accordance with the present invention generally provide odds of winning which are generally better than a lottery, and with a huge entertainment value. Mega Pools may allow internet gaming to capture a huge part of the available market share.

With Mega Pools, the consolation prize becomes the real prize; the opportunity to move one step closer to the big prize. Mega Pools may provide benefits to online gaming such as: making a football or basketball pool a major event at any denomination; leading players not to care which pool they are in, just that they are in a pool with a chance to move forward towards the big prize; making every game saleable, not just big games, TV games, playoff games or the main event; increasing basketball pool sales, because every number is a good number; increasing Speed Pool sales because the player can buy and buy until they get a good number; leading players to hope they win the consolation price, that pays nothing, but moves them one step closer to winning up to 10,000 times their original investments; allowing the administrator to pick the “Bonus Pool” game or games; placing no specific time frame on accumulating the number of consolation prize winners to fill the bonus pools because a square in a bonus pool is picked for a game to be announced.

In one example, a one billion dollar Mega Pool is possible. To be able to offer a prize of this magnitude, the biggest in gaming/lottery history, 10,000 pools at $100,000.00 a square would need to be sold. 10,000 pools translates to one million squares sold; equivalent to 100 billion dollars in sales. 100 billion dollars in sales would produce a 10 billion dollar rake and 1 billion dollar prize to be given away. Currently the entire internet market revenue is between 12 and 15 billion dollars a year, but the available worldwide market, gambling and lottery (e.g., the sum of all wagers), is probably in excess of 1.4 trillion dollars. 100 billion dollars would result from capturing about 7.1% of the available market. A daunting task no doubt. However, worldwide there are over 8 million millionaires and close to 1 thousand billionaires that control trillions of dollars. If 4 million people worldwide split the squares, each putting in $25,000.00, the sale of 1 million squares would be complete. 4 million players is less then one tenth of one percent of the world population.

In one example, pool clubs, similar to lottery clubs, may be formed. For example, clubs with as many as 100 members could be formed, with each contributing $1,000 toward buying one square for the chance to win a share of the 1 billion dollars (e.g., $10,000,000.00 each). Alternatively, ten people could contribute $10,000 each to buy one square for the chance at sharing the “Mega Pools” 1 billion dollar prize (e.g., 100,000,000.00 each). Mega Pools may provide a truly worldwide game. Another benefit is that in route to the billion dollar Mega Pool prize 40,000 lucky winners will have received $2,250,000.00 each in regular prize winnings. Mega Pools could catapult internet gaming from an industry with current revenues in excess of 12 billion dollars to an amount twice that figure in less than one year. Although selling one million $100,000 squares may be overly ambitious, selling billions of dollars worth of five, ten, twenty, fifty, one hundred and one thousand dollars squares that result in Mega Pool payouts of up to 10,000 times the original wager, is most certainly attainable.

Since at any denomination, one million single squares are sold to arrive at one Mega Pool, the question becomes whether any one site is capable of handling the volume. Although selling a million squares for $5.00, $10.00, $20.00, $50.00 and even $100.00, could be sold through one site, a “parent” or “mother” site may be set up to provide a unified approach. For example, a central, behind the scenes site, that acts as a square warehouse, could be set up to supply hundreds of individual sites, like a wheel with hundreds of spokes. Instead of running software on individual sites, a central site may be implemented to act as the warehouse. For example, a company (e.g., Pinnacle, Heritage, Bodog, William Hill, etc.) may have a link (e.g., “Pinnacle Squares”, etc.) that when clicked on, directs the player to the warehouse. The warehouse may be configured to appear to be the referring site (e.g., Pinnacle, Heritage, Bodog, William Hill, etc.). Although everyone would see the same home page, “Pinnacle” customers would see “Pinnacle Squares, Home of the Mega Pools”, “Heritage” customers would see “Heritage Squares, Home of the Mega Pools” and so on. The customers would buy squares that, although appearing to be just “Pinnacle Pools”, are in reality community pools offered to hundreds of other sites. So, at the same time that a “Pinnacle” customer is buying a $5.00 square from a specific pool, a “Heritage” customer may be buying a square from the same pool, and the same with a “Bodog” customer and a “William Hill” customer.

In the background, each individual square purchased may be tagged with an indication specific to the originating site. The parent (or central) site would have control with regard to pool creation, bonus pool creation, mega pool creation, sports schedule and score feeds and so forth. Under this scenario, the 10% rake may be split between the entities as follows: 5% to satellite sites that refer the customer, 4% to the central site, and 1% placed in the Mega Pool jackpot. The central site could have hundreds of feeding-sites with their own “skin page”, and behind the scenes, the central site handles all administrative details. When a purchase is made, for instance by a “Pinnacle” customer, “Pinnacle” automatically transfers funds from the customer account to the central site, less their percentage.

In one example, Mega Pools may change the face of internet gaming and in the process turn a 100 dollar customer wager into a $1,000,000.00 return. Mega Pool sales could provide a worldwide lottery, but with much more entertainment value. Mega Pools could be offered with odds of up to 10,000 to 1. To reach the maximum payout of 10,000 to 1, 10,000 regular pools would be sold out. In one example, using a $5.00 per square original value, if only 6,500 regular pools are sold out, a progressive “Mega Pool Jackpot” counter specific to that pool would read “$32,500.00”. In this example, 65 customers would eventually advance as “Bonus Pool” winners into the “Mega Pool”. The remaining 35 squares would become house squares. The house would be ineligible to win in any “Mega Pool”, thus, if a house square is determined as the “Final Score” winner, the real winner would then be determined, for example, in the following reverse order: “Final Score” reverse, 3^(rd) quarter, 2^(nd) quarter, and finally 1^(st) quarter. If the house continues to win in reverse order then the jackpot may be evenly distributed equally between the 65 customers, who would then receive $500.00 each, or 100 times their original wager. With larger pools, the straight winner may be given a choice of accepting the winnings or forfeiting the winnings to the reverse consolation prize winner and moving on to the bonus round and a chance at the big prize.

As used herein, the term web application is meant to include any application that communicates over a network or the internet. As used herein, the terms visitor, member, user, and player are used interchangeably. As used herein, the term “simultaneously” is meant to describe events that share some common time period but the term is not meant to be limited to events that begin at the same point in time, end at the same point in time, or have the same duration.

The function performed by the diagrams of FIGS. 1-6 may be implemented using a conventional general purpose digital computer programmed according to the teachings of the present specification, as will be apparent to those skilled in the relevant art(s). Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s).

The present invention may also be implemented by the preparation of ASICs, FPGAs, or by interconnecting an appropriate network of conventional component circuits, as is described herein, modifications of which will be readily apparent to those skilled in the art(s).

The present invention thus may also include a computer product which may be a storage medium including instructions which can be used to program a computer to perform a process in accordance with the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disk, optical disk, CD-ROM, magneto-optical disks, ROMs, RAMs, EPROMS, EEPROMs, Flash memory, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the spirit and scope of the invention. 

1. A computer readable medium containing computer executable instructions, which, when executed by a computer, perform the steps of: (A) generating one or more pools; (B) generating a set of random numbers for each of the one or more pools when the one or more pools are generated; (C) encrypting each set of random numbers; and (D) generating instructions to display a graphical representation of the one or more pools in response to a user request, wherein the graphical representation comprises a plurality of graphical devices, each aligned with a respective row or column of a grid, and wherein the graphical devices display the set of random numbers after performing a predetermined animated sequence.
 2. The computer readable medium according to claim 1, wherein a plurality of users, each located in a different location and purchasing squares in the same pool, are (i) entered simultaneously into the same pool and (ii) sent the respective square numbers for the squares purchased.
 3. The computer readable medium according to claim 1, wherein the one or more pools comprise one or more payout types selected from the group consisting of straight, straight/reverse, progressive and progressive/reverse.
 4. The computer readable medium according to claim 1, wherein the one or more pools comprise one or more pool types selected from the group consisting of regular pools, speed pools, mini pools, private pools, bonus pools and mega pools.
 5. The computer readable medium according to claim 4, wherein the mini pools comprise combined straight and straight/reverse pools.
 6. The computer readable medium according to claim 4, further comprising instructions for individually configuring the mega pools with odds of up to 10,000 to
 1. 7. The computer readable medium according to claim 1, further comprising instructions for forming one or more pool clubs, wherein a purchase price of one or more squares is split among members of a respective one of the one or more pool clubs.
 8. The computer readable medium according to claim 1, further comprising instructions to allow a winner of a pool to choose between receiving a payout or being entered into a bonus pool.
 9. A method for providing entertainment via the internet comprising the steps of: (A) generating one or more pools; (B) generating a set of random numbers for each of the one or more pools when the one or more pools are generated; (C) encrypting each set of random numbers; and (D) generating instructions to display a graphical representation of the one or more pools in response to a user request, wherein the graphical representation comprises a plurality of graphical devices, each aligned with a respective row or column of a grid, and wherein the graphical devices display the set of random numbers after performing a predetermined animated sequence.
 10. The method according to claim 9, further comprising the steps of: simultaneously entering a plurality of users, each located in a different location and purchasing squares in the same pool, into the same pool; and simultaneously sending the respective square numbers for the squares purchased to the plurality of users.
 11. The method according to claim 9, wherein the one or more pools comprise one or more payout types selected from the group consisting of straight, straight/reverse, progressive and progressive/reverse.
 12. The method according to claim 9, wherein the one or more pools comprise one or more pool types selected from the group consisting of regular pools, speed pools, mini pools, private pools, bonus pools and mega pools.
 13. The system according to claim 12, wherein the mini pools comprise combined straight and straight/reverse pools.
 14. The method according to claim 12, further comprising the step of individually configuring the mega pools with odds of up to 10,000 to
 1. 15. The method according to claim 12, further comprising the steps of: designating a pool as a bonus pool; and offering a winner of a regular pool a choice of receiving a payout or being entered into the bonus pool.
 16. The method according to claim 9, further comprising the steps of: forming one or more pool clubs; and splitting a purchase price of one or more squares among members of a respective one of the one or more pool clubs.
 17. A system for providing entertainment comprising: a first computer configured to generate one or more pools; a random number generator configured to generate a set of random numbers for each of the one or more pools when the one or more pools are generated; and an encoder configured to encrypt each set of random numbers, wherein said computer is configured to send information via a communication network for controlling a second computer to display a graphical representation of the one or more pools in response to a user request, and wherein the graphical representation comprises a plurality of graphical devices, each aligned with a respective row or column of a grid, and wherein the graphical devices display the set of random numbers after performing a predetermined animated sequence.
 18. The system according to claim 17, wherein the one or more pools comprise one or more payout types selected from the group consisting of straight, straight/reverse, progressive and progressive/reverse and one or more pool types selected from the group consisting of regular pools, speed pools, mini pools, private pools, bonus pools and mega pools.
 19. The system according to claim 17, wherein the first computer comprises a central server configured to communicate with a plurality of second computers through a plurality of intermediate computers.
 20. The system according to claim 17, wherein the first computer is further configured to customize the graphical representation of the one or more pools according to the respective one of the plurality of second computers on which the graphical representation is displayed. 